Recently I’ve been looking into giving my WFH setup some upgrade.
I already have a 38inch AW3821DW monitor running 3800x1600 @ 144Hz, connected to the M1 Pro Macbook Pro via a TB3 dock (StarTech TB3DOCK2DPPD that I bought years ago pre-pandemic). I’m trying to add a side monitor to it with likely a QHD spec (2560x1440) @ 100Hz.

Then I suddenly realized one thing, if I want to keep my connection topology as is (wire up all devices to my dock and connect it to the Mac using a single TB cable) - would that work?

It turns out it’s not that straightforward to average users. And here’s why.

1) RGB 4:4:4 vs YCbCr 4:2:2 Chroma Subsampling

Before doing math, we first need to check the signal we want to drive:

• RGB/YCbCr 4:4:4, 8-bit per channel (bpc) → 24 bits/pixel. This is the “no-compromise” desktop signal—full chroma on every pixel. Text looks crisp.
• YCbCr 4:2:2, 8-bpc → the chroma (Cb/Cr) is shared between two horizontal pixels, averaging 16 bits/pixel (≈ 33% less data than 4:4:4). Saves bandwidth, but fine colored edges and UI text soften.
• YCbCr 4:2:0, 8-bpc → 12 bits/pixel (≈ 50% less than 4:4:4). Great for video, not for desktop use.
• HDR / 10-bpc pushes each of those up by 25% (e.g., RGB 4:4:4 becomes 30 bits/pixel).

For SDR productivity monitors, we should ALWAYS prefer RGB 4:4:4 (or YCbCr 4:4:4) at 8-bpc for clear text.
Anything doing chroma subsampling (422) is a no-go as text would have blurred/colored edges. Period.

2) The bandwidth calculation

For uncompressed links (DisplayPort/HDMI without DSC), a solid back-of-the-envelope is:

This yields the active video payload. Real links also carry blanking intervals and link-layer overhead. Using modern reduced-blanking timings, a 5–10% headroom usually suffices for comparisons; standards bodies quote separate “link rates” that already include line coding overhead.

Let’s compute the key cases (all at 8-bpc unless noted):

• One QHD (2560×1440) @ 100 Hz, 4:4:4
  

  $$2560 \times 1440 \times 100 \times 24 \;=\; \mathbf{8.85\ Gbps}$$
  
  With 10-bpc (30 bpp): 11.06 Gbps.
  With 4:2:2 (16 bpp): 5.90 Gbps.

• Your ultrawide (3840×1600), 4:4:4

  • @ 100 Hz
    
    $$3840 \times 1600 \times 100 \times 24 = \mathbf{14.75\ Gbps}$$
  • @ 120 Hz 17.69 Gbps (already nudging past DP 1.2’s effective limit once overhead is considered).
  • @ 144 Hz: 21.23 Gbps (firmly beyond DP 1.2; needs DP 1.4/HBR3 and/or DSC support end-to-end).

• Two monitors together:

  • 3840×1600 @ 100 Hz + 2560×1440 @ 100 Hz (both 8-bpc 4:4:4) →
    
    $$14.75 + 8.85 \approx \mathbf{23.6\ Gbps}$$
    
    This is in the same ballpark as dual 4K60 8-bpc (≈ 23.9 Gbps active), which many Thunderbolt 3 docks explicitly support.

Interpreting against link limits

• DisplayPort 1.2 (HBR2): Max 17.28 Gbps payload per DP link. One 2560×1440@100 (8-bpc 4:4:4) fits comfortably. One 3840×1600@100 fits. 3840×1600@120 does not, and @144 certainly does not.
• DisplayPort 1.4 (HBR3): Max 25.92 Gbps payload per DP link. Enough for 3840×1600@120/144 uncompressed in many timing modes, or with DSC when needed.

3) DP 1.4 vs DP 1.2—and how that relates to Thunderbolt versions

• DP 1.2 (HBR2) tops out at 5.4Gbps/lane x 4 - 21.6 Gbps raw / 17.28 Gbps effective payload.
• DP 1.4 (HBR3) increases the lane rate to 8.1Gbps/lane -> 32.4 Gbps raw / 25.92 Gbps effective and adds features like DSC 1.2 for higher-than-link-rate modes.
• Thunderbolt 3 originally shipped on Alpine Ridge controllers that tunnel DP 1.2 only. Later Titan Ridge TB3 silicon can tunnel DP 1.4.
• Thunderbolt 4 is built on USB4 v1; it mandates support for two 4K displays or one 8K display, functionally aligning with DP 1.4/HBR3 tunneling end-to-end. (TB4 does not raise the nominal 40 Gbps link rate; it raises the minimums OEMs must deliver.)

However, the StarTech TB3DOCK2DPPD is an older Alpine Ridge (JHL6540) design—i.e., DP 1.2-only on its display paths. It still handles dual-display by presenting two DP sinks to the host TB controller (one on the rear DisplayPort jack, and a downstream TB3 port). But each DP hop is capped at DP 1.2 timings.

4) M1 Pro limitations and why a downstream Thunderbolt port matters

At this moment, it’s roughly clear that a TB3 dock is not going to be sufficient bandwidth wise.

However there’s a bit more nuance here (and why we actually need a higher-end dock with a downstream TB4 port):

• M1 Pro MacBook Pro (2021) supports up to two external displays over Thunderbolt (each up to 6K60). That’s a hard GPU/display-engine limit on count, not just raw bandwidth.
• MacOS does not support DisplayPort MST for extended desktops. In plain English: you can’t split one DP lane group into two independent desktops via an MST hub and expect macOS to see two displays—it will mirror them.
  Implication: to run two external monitors over one cable, we need a Thunderbolt dock that exposes two independent DP tunnels (e.g., one physical DP output plus a downstream TB port for the second display via USB-C→DP).

The TB3DOCK2DPPD does exactly that: one native DP port and one downstream TB3 port intended to carry the second display. The constraint, again, is that both of those hops are DP 1.2 only.

A lot of the lower-end docks, on the other hand, do NOT carry downstream TB ports and hence not suited for such setup.

Putting it together:

• To keep the single-cable topology, we should use the dock’s DP for one monitor and the downstream TB3→USB-C/DP for the other.
• We also need a DP 1.4-capable TB3/TB4 dock (Titan Ridge, Goshen Ridge/TB4) to fulfill the bandwidth requirements for the 2 monitors at high refresh rate.

5) Summary

• Yes, the single-cable topology can work—with caveats. On the Alpine Ridge TB3 dock (DP 1.2), run the AW3821DW at 100 Hz and the new 2560×1440 at 100 Hz, both at 8-bpc RGB 4:4:4.
• The dock will not do 3840×1600 @ 144 Hz concurrently with a high-refresh second display; DP 1.2 per-link bandwidth is the blocker.
• Because macOS lacks MST-Extended, we also need to ensure the dock provides a downstream Thunderbolt port.

References

[1] Apple — MacBook Pro (14-inch, 2021) Tech Specs (external display support) – https://support.apple.com/en-us/111902
[2] Dell — Alienware AW3821DW product page (3840×1600 @ 144 Hz over DP) – https://www.dell.com/en-us/shop/alienware-38-curved-gaming-monitor-aw3821dw/apd/210-axvg/monitors-monitor-accessories
[3] RTINGS — Chroma Subsampling: 4:4:4 vs 4:2:2 vs 4:2:0 – https://www.rtings.com/tv/learn/chroma-subsampling
[4] Eaton/Tripp Lite — DisplayPort explained (8b/10b vs 128b/132b; effective payloads) – https://www.eaton.com/us/en-us/products/backup-power-ups-surge-it-power-distribution/backup-power-ups-it-power-distribution-resources/cpdi-vertical-marketing/displayport-explained.html
[5] Cable Matters — DisplayPort 1.4 vs 1.2: What’s the Difference? (21.6 vs 32.4 Gbps raw; 17.28 vs 25.92 Gbps payload) – https://www.cablematters.com/Blog/DisplayPort/displayport-1-4-vs-1-2
[6] Wikipedia — DisplayPort (TB3 Alpine Ridge DP 1.2 vs Titan Ridge DP 1.4) – https://en.wikipedia.org/wiki/DisplayPort
[7] StarTech — TB3DOCK2DPPD Manual (identifies JHL6540 Alpine Ridge chipset, DP 1.2 heritage) – https://sgcdn.startech.com/005329/media/sets/tb3dock2dppd_manual/tb3dock2dppd_tb3dock2dppu_thunderbolt_3_dock.pdf
[8] StarTech — TB3DOCK2DPPD Datasheet (dual-4K60 via DP + downstream TB3) – https://media.startech.com/cms/pdfs/tb3dock2dppd_datasheet.pdf
[9] Plugable KB — MST on macOS (Extended not supported) – https://kb.plugable.com/understanding-mst-multi-display-setups-with-windows-macos-and-displayport
[10] Intel — Thunderbolt 3 vs Thunderbolt 4 (TB4 mandates dual 4K or one 8K) – https://www.intel.com/content/www/us/en/architecture-and-technology/thunderbolt/thunderbolt-3-vs-4.html
[11] Wikipedia — USB4 (DP 1.4a tunneling in USB4 v1; DP 2.1 in USB4 v2) – https://en.wikipedia.org/wiki/USB4

Comment and share

Update

• (2018.11) Oozie has Kerberos auth over SPNEGO for web (thanks to Justin Miller for pointing it out)

Disclaimer

I’m not an expert in any of those engines.
I’ve used some of those (Airflow & Azkaban) and checked the code.
For some others I either only read the code (Conductor) or the docs (Oozie/AWS Step Functions).
As most of them are OSS projects, it’s certainly possible that I might have missed certain undocumented features,
or community-contributed plugins. I’m happy to update this if you see anything wrong.

Bottom line: Use your own judgement when reading this post.

Airflow

The Good

Airflow is a super feature rich engine compared to all other solutions.
Not only you can use plugins to support all kinds of jobs,
ranging from data processing jobs: Hive, Pig (though you can also submit them via shell command),
to general flow management like triggering by existence of file/db entry/s3 content,
or waiting for expected output from a web endpoint,
but also it provides a nice UI that allows you to check your DAGs (workflow dependencies) through code/graph,
and monitors the real time execution of jobs.

Airflow is also highly customizable with a currently vigorous community.
You can run all your jobs through a single node using local executor,
or distribute them onto a group of worker nodes through Celery/Dask/Mesos orchestration.

The Bad

Airflow by itself is still not very mature (in fact maybe Oozie is the only “mature” engine here).
The scheduler would need to periodically poll the scheduling plan and send jobs to executors.
This means it along would continuously dump enormous amount of logs out of the box.
As it works by “ticking”, your jobs are not guaranteed to get scheduled in “real-time” if that makes sense
and this would get worse as the number of concurrent jobs increases.
Meanwhile as you have one centralized scheduler, if it goes down or gets stuck, your running jobs won’t be
affected as that the job of executors, but no new jobs will get scheduled. This is especially confusing when
you run this with a HA setup where you have multiple web nodes, a scheduler, a broker
(typically a message queue in Celery case), multiple executors. When scheduler is stuck for whatever reason,
all you see in web UI is all tasks are running, but in fact they are not actually moving forward while executors
are happily reporting they are fine. In other words, the default monitoring is still far from bullet proof.

The web UI is very nice from the first look. However it sometimes is confusing to new users.
What does it mean my DAG runs are “running” but my tasks have no state? The charts are not search friendly either,
let alone some of the features are still far from well documented
(though the document does look nice, I mean, compared to Oozie, which does seem out-dated).

The backfilling design is good in certain cases but very error prone in others.
If you have a flow with cron schedules disabled and re-enabled later, it would try to play catch up,
and if your jobs is not designed to be idempotent, shit would happen for real.

Azkaban

The Good

Of all the engines, Azkaban is probably the easiest to get going out of the box.
UI is very intuitive and easy to use. Scheduling and REST APIs works just fine.

Limited HA setup works out of the box.
There’s no need for load balancer because you can only have one web node.
You can configure how it selects executor nodes to push jobs to and it generally seems to scale pretty nicely.
You can easily run tens of thousands of jobs as long as you have enough capacity for the executor nodes.

The Bad

It is not very feature rich out of the box as a general purpose orchestration engine,
but likely that’s not what’s originally designed for. It’s strength lies in native support for Hadoop/Pig/Hive,
though you can also achieve those using command line. But itself cannot trigger jobs through external resources like
Airflow, nor does it support job waiting pattern. Although you can do busy waiting through java code/scripts, that
leads to bad resource utilization.

The documentation and configuration are generally a bit confusing compared to others. It’s likely that it wasn’t supposed
to be OSed at the beginning. The design is okish but you better have a big data center to run the executors as scheduling
would get stalled when executors run out of resources without extra monitoring stuff. The code quality overall is a bit towards
the lower end compared to others so it generally only scales well when resource is not a problem.

The setup/design is not cloud friendly. You are pretty much supposed to have stable bare metal rather than dynamically
allocated virtual instances with dynamic IPs. Scheduling would go south if machines vanish.

The monitoring part is sort of acceptable through JMX (does not seem documented). But it generally doesn’t work well if your
machines are heavily loaded, unfortunately, as the endpoints may get stuck.

Conductor

The Good

It’s a bit unfair to put Conductor into this competition as it’s real purpose is for microservice orchestration, whatever that means.
It’s HA model involves a quorum of servers sitting behind load balancer putting tasks onto a message queue which the worker nodes would
poll from, which means it’s less likely you’ll run into stalled scheduling.
With the help of parameterized execution through API, it’s actually quite good at scheduling and scaling provided
that you set up your load balancer/service discovery layer properly.

The Bad

The UI needs a bit more love. There’s currently very limited monitoring there. Although for general purpose scheduling that’s probably
good enough.

It’s pretty bare-bone out of the box. There’s not even native support for running shell scripts, though it’s pretty easy to implement
a task worker through python to do the job with the examples provided.

Oozie

The Good

Oozie provides a seemingly reliable HA model through the db setup (seemingly b/c I’ve not dug into it).
It provides native support for Hadoop related jobs as it was sort of built for that eco system.

The Bad

Not a very good candidate for general purpose flow scheduling as the XML definition is quite verbose
and cumbersome for defining light weight jobs.

It also requires quite a bit of peripheral setup. You need a zookeeper cluster, a db, a load balancer
and each node needs to run a web app container like Tomcat. The initial setup also takes some time which is
not friendly to first time users to pilot stuff.

Step Functions

The Good

Step Functions is fairly new (launch in Dec 2016). However the future seems promising. With the HA nature of cloud
platform and lambda functions, it almost feels like it can easily scale infinitely (compared to others).

It also offers some useful features for general purpose workflow handling like waiting support and dynamic branching
based on output.

It’s also fairly cheap:

• 4,000 state transitions are free each month
• $0.025 per 1,000 state transitions thereafter ($0.000025 per state transition)

If you don’t run tens of thousands of jobs, this might be even better than running your own cluster of things.

The Bad

Can only be used by AWS users. Deal breaker if you are not one of them yet.

Lambda requires extra work for production level iteration/deployment.

There’s no UI (well there is but it’s really just a console).
So if you need any level of monitoring beyond that you need to build it using cloudwatch by yourself.

Comment and share

Table of Contents

1. == and ===
2. Dig deeper
   1. What about arrays?
   2. What about objects
3. Implicit conversions
4. Conclusion

== and ===

Likely you know the difference between == and ===: basically, === means strict equality where no implicit conversion is allowed whereas == is loose equality.

1
2
3
4

'a' === 'a'     // true
0 == false      // true

Dig deeper

OK but this is too boring since we all know that.

How about this:

1
2
3
4

String('a') === 'a'
new String('a') === 'a'

Well the answers are true and false because String() returns a primitive string while new String() returns a string object. Surely new String('a') == 'a' yields true. No surprise.

What about arrays?

[] === []

Well this returns false because for non-primitive objects, they are compared by reference. This always returns false because they are different in terms of memory location.

However surprisingly you can compare arrays like this:

[1, 2, 3] < [2, 3]      // true
[2, 1, 3] > [1, 2, 3]   // true

(Wait a sec. I think I have an idea.)

How about this:

function arrEquals(arr1, arr2) {
    return !(arr1 < arr2) && !(arr2 < arr1);
}

Well this is wrong because arrays will be flattened when compared, like this

[[1, 2], 1] < [1, 2, 3]     // true

What about objects

What’s the result of this expression?

{} === {}

Well it’s neither true nor false but you get SyntaxError because in this case {} is not an object literal but a code block and thus it cannot be followed with =. Anyway we are drifting away from the original topic…

Implicit conversions

Well that’s just warm-up. Let’s see something serious.

If you read something about “best practices”, you would probably be told not to use == because of the evil conversion. However chances are you’ve used it here and there and most likely that’s also part of the “best practices”.

For example:

var foo = bar();
if (foo) {
    doSomething();
}

This works because in JavaScript, only 6 object/literals are evaluated to false. They are 0, '', NaN, undefined, null and of course false. Rest of the world evaluates to true, including {} and [].

Hmm here’s something wacky:

1
2
3
4
5
6
7
8
9
10
11

var a = {
    valueOf: function () {
        return -1;
    }
};

if (!(1 + a)) {
    alert('boom');
}

Your code does go boom because 1 + a gets implicitly converted to 1 + a.valueOf() and hence yields 0.

The actual behavior is documented in ECMA standard - http://www.ecma-international.org/ecma-262/6.0/#sec-abstract-equality-comparison

In most cases, implicit conversion would cause valueOf() to be called or falls back to toString() if not defined.

For example:

1
2
3
4
5
6
7
8
9
10
11
12

var foo = {
    valueOf: function () {
        return 'value';
    },
    toString: function () {
        return 'toString';
    }
};

'foo' + foo             // foovalue

This is because according to standard, when toPrimitive is invoked for implicit conversion with no hint provided (e.g. in the case of concatenation, or when == is used between different types), it by default prefers valueOf. There are a few exceptions though, including but not limited to Array.prototype.join and alert. They would call toPrimitive with string as the hint so toString() will be favored.

Conclusion

In general, you probably want to avoid using == and use === most of the time if not always to avoid worrying about wonky implicit conversion magic.

However, you can’t be wary enough. For example:

isNaN('1') === true

You might think that '1' is a string and hence this should be false but unfortunately isNaN always calls toNumber internally (spec) and hence this is true.

Comment and share